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Introduction 


In  the  past  few  years  there  has  been  a  rapid  acceleration  in  the  study 
of  the  implementation  of  computer-based  decision  aids.   Most  of  this  research 
is  centered  around  two  basic  questions: 

1.  What  are  the  key  variables  -  organizational,  individual,  and  technical 
-  relevant  to  the  implementation  process? 

2.  What  are  the  common  patterns  in  either  successful  or  unsuccessful  im- 
plementation efforts? 

The  research  is  generally  exploratory;  much  of  it  is  data-gathering  rather 
than  theory-building  or  theory-testing  and  involves  surveying  large  samples 
of  projects  in  various  organizations  or  industries  through  structured  interviews 
and  questionnaires.   The  results  are  sifted  to  identify  clusters  of  variables 
-  'factors'  -  that  are  interrelated  and  that  correlate  with  some  measure  of  im- 
plementation success,  such  as  user  satisfaction.   This  sifting  is  generally 
atheoretical  and  aims,  in  fact,  at  inducting  a  base  for  theory.! 

In  assessing  the  value  of  such  research  on  implementation,  and  in  drawing 
conclusions  from  it,  it  is  essential  to  stress  how  recent  the  topic  is,  even 
though  it  is  also  increasing  in  visibility  and  frequency  of  reference  (to  the 
extent  that  'Implementation'  seems  to  be  taking  over  from  'Design'  in  the 
titles  of  journal  articles).   There  is  a  Standard  Paragraph  that  begins  many 
discussions  of  implementation  -  including,  of  course,  this  one.   It  starts  by 
pointing  out  that  implementation  ^  a  very  recent  topic:   Batchelor's  biblio- 
graphy of  the  OR/MS  literature  in  1965  did  not  even  include  the  term  in  its 
index. 2   Radnor  and  Mylan's  1968  literature  search  found  only  15  out  of  750 
articles  focused  on  implementation. 3  Even  more  gloomily.  Urban  reports  that 
only  3  percent  of  the  150  articles  published  in  Management  Science;  App- 
lication between  January  1971  and  June  1973  represented  implementation. 

The  Standard  Paragraph  then  moves  on  to  point  out  that  there  is  an  im- 
plementation crisis,  and  that  many  more  systems  are  built  than  are  used.   The 
1960 's  version  of  the  S.P.  would  cite  Churchman's  finding  (196A)  that  in  six 
years'  issues  of  Operations  Research  Quarterly  there  was  virtually  no  evidence 
that  any  of  the  models  discussed  were  ever  used.-*  The  1975  version  could  re- 
inforce this  from  a  variety  of  sources.   Drake  (1973),  in  surveying  computer 
models  for  transportation  planning,  was  able  to  identify  expenditures  of  over 
a  million  dollars  a  year";   while  some  of  the  models  were  never  completed  and 
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sank  after  'disagreement  and  disaster',  the  ones  that  were  'successfully' 
built  seemed  rarely,  if  at  all,  used  by  the  decision  makers  for  whom  they 
were  commissioned.   The  Standard  Paragraph  then  closes  by  bemoaning  our 
lack  of  empirical  data  and/or  theory  and  promises  to  solve  the  world  or 
tentatively  explore  it,  depending  on  how  good  the  researcher's  own  data  has 
turned  out  to  be. 

The  Standard  Paragraph  highlights  our  very  defensive  position  on  im- 
plementation. There  is  a  crisis  and  we  have  little  wisdom  to  offer.  In 
parallel  to  this  -  perhaps  even  in  reaction  to  it  -  there  seems  to  be  an 
increasing  anti-academic  bias  among  managers  and  practicioners  who  care 
about  the  Implementation  Gap,  with,  in  particular,  an  attack  on  schools  of 
management  for  not  providing  the  right  training  in  the  troops  they  send  out 
onto  the  battlefield.   An  insightful  illustration  of  this  attack  can  be  found 
in  a  panel  discussion  from  the  1971  national  TIMS  meeting  which  later  appear- 
ed under  the  title  "Through  a  Glass  Darkly"  in  Interfaces  (August  1911)  J      It 
contains  brief  presentations  by  six  practicioners,  all  of  whom  are  well-known 
and  active  participants  in  MS  and  MIS  societies  and  who,  therefore,  have  been 
true  believers  in  and  missionaries  for  the  Analytic  Method.   Their  arguments 
are  uniform  in  tone;  the  following  extracts  are  representative  of  their  dis- 
cussion : 

Table  1  Through  a  Glass  Darkly 

H.  Halbrecht  (Chairman  Halbrecht  Associates,  management  recruiting  company 
with  substantial  experience  in  recruiting  senior  OR  and  MIS 
personnel) 
"...the  obvious  fact  that  many  people  have  not  been  willing  to  face 
(is)  that  the  management  science  profession  is  in  trouble.   It  is  in 
substantial  trouble  and  in  many  cases  well-deserved  trouble." 

E.S.  Savas  (First  Deputy  City  Administrator,  Mayor's  Office,  New  York  City) 
"How  to  Make  OR  Fail  Without  Really  Trying" 

"...  We  have  been  reluctant  to  hire  people  with  Ph.D. 's  in  OR  on  the 
grounds  that  they  have  acquired  'a  trained  incapacity  to  think'  (Herman 
Kahn) ,  a  rigidity  brought  on  by  some  forms  of  higher  education..." 

G.  Hoffman  (Manager  of  Operations  Research,  Standard  Oil  of  Indiana) 
"The  Missing  90%  of  Management  Science" 

"...  The  graduates  of  OR  curricula  are  not  adequately  trained  in  OR.  I 
now  make  a  more  damning  assertion;  usually  these  graduates  are  not  edu- 
cated at  all." 


H.  Ay res  (Vice-President  for  Operations  Research,  Morgan  Guaranty) 
"Skills  for  Effective  Management  Science" 

"...We've  really  made  very  few  job  offers  (to  OR  graduates).   What 
stands  out  in  my  mind  is  that  I  don't  think  many  of  them  realize 
what  OR/MS  really  is.   Who  is  to  blame  for  this?  Let's  try  blaming 
the  academicians  who  train  them   these  people.   They  do  not  train  them  in 
OR/MS;  they  train  them  in  applied  mathemtics  and  that's  all." 

Many  of  the  panel's  strictures  may  be  less  true  now  than  in  1971;  cer- 
tainly most  management  schools  are  sensitive  to  the  issues  they  raise  and 
there  has  been  a  tremendous  growth  in  applied  research  and  training.   None 
the  less,  the  points  have  much  force;  they  highlight  the  well-entrenched 
bias  that  has  led  to  many,  if  not  most  OR/MS /MIS  specialists  defining  their 
role  in  terms  of  technical  and  design  skills,  rather  than  as  implementers. 
The  panel's  attack  focuses  on  the  lack  among  analytic  specialists  of: 

1.  an  understanding  of  how  decisions  are  really  made 

2.  insight  into  and  identification  with  managers 

3.  an  ability  to  relate  technique  to  context 

A.   a  view  of  their  role  as  supporting  the  management  process 
An  obvious  recent  continuation  of  this  theme  is  C.  Jackson  Grayson's  crit- 
icism of  the  value  of  management  science  methods  based  on  his  experiences  as 
chairman  of  the  Federal  Price  Commission  (Harvard  Business  Review,  July  1973) 
"Management  Science  and  Business  Practice".   Grayson,  like  the  panel  in 
"Through  a  Glass  Darkly",  is  no  ignorant  outsider,  but  a  veteran  in  teaching 
and  supporting  analytic  skills.   His  article  suggests  the  disillusion  of  a 
lost  faith: 

"Managers  and  management  scientists  are  operating  as  two  separate 
cultures,  each  with  its  own  goals,  languages  and  methods.   Effective 
cooperation  -  and  even  communication  -  between  the  two  is  just  about 
minimal. S" 

Grayson's  solution  to  the  implementation  problem  is  one  that  many  other 
writers  have  suggested:   training  the  manager  and  the  management  scientist 
towards  a  common  middle  ground,  so  that  both  have  mutual  understanding  and 
shared  skills.   That   solution  may  be  very  difficult  to  effect  in  that  mana- 
gers and  specialists  are  generally  unwilling,  unable  or  too  overburdened  to 
spend  time  acquiring  new  skills  that  are  of  marginal  value  in  their  present 
jobs.   More  importantly,  the  main  value  of  the  specialist  is  his  specializa- 
tion.  The  methodological,  rigorous  analytic  approach  to  problem-solving 
that  is  the  idiosyncratic  gift  of  the  management  scientist  is  fairly  unusual; 
it  is  applicable  in  particular  contexts  only  and  represents  an  expertise  that 


is  valuable  mainly  because  of  its  specialized  availability  and  applicability. 
In  passing,  it  is  worth  noting  that  several  researchers  who  have  examined  the 
'cognitive  styles'  of  managers  and  management  scientists  strongly  imply  that 
the  scientist's  skills  presuppose  a  particular  mode  of  thinking  that  is  ex- 
tremely hard  to  develop  among  many  managers,  whose  equally  distinctive  abili- 
ties are  built  on  an  entirely  different  set  of  problem-solving  strategies  and 
habits. 9 

All  the  quotations  cited  above  reinforce  our  defensive  posture  about  both 
research  on  and  practice  in  implementation.   They  clearly  suggest  that  manage- 
ment scientists  must  develop  a  more  effective  role;  of  course,  many  counter- 
attacks reach  a  parallel  conclusion  that  managers  must  develop  new  knowledge 
and  be  much  more  willing  to  take  an  active  part  in  the  implementation  process. 
While  this  defensiveness  and  rather  negative  position  is  widespread,  it  repre- 
sents a  pessimism  that  is  expressed  rather  than  believed.   When  we  stop  to 
think  about  the  general  achievements  of  OR/MS/MIS  there  is   ample  reason  for 
disillusion  and  yet,  as  a  profession,  management  scientists  and  educators  in 
analytic  subject  areas  obviously  feel  that  they  are  having  a  beneficial  impact 
on  organizational  decision-making  and  that,  on  the  whole.  Progress  is  being 
made  (though  they  will  admit  that  perhaps,  in  the  past,  there  was  a  tiny  bit 
too  much  overselling).   To  a  large  extent,  the  emerging  focus  on  implementation 
and  the  context  of  techniques,  rather  than  on  technique  in  itself,  implies  a 
welcome  maturation  within  the  management  science  field.   Five  years  or  so  ago, 
the  central  issue  was  the  development  of  relevant  techniques;  now  those  tech- 
niques are  generally  well-understood  and  there  is  a  sufficient  body  of  experience 
with  them  -  negative  as  well  as  positive  -  to  highlight  issues  beyond  the 
design  of  models  and  systems.   The  strictures  made  by  the  panel  of  Through  a 
Glass  Darkly  are  justified  but  they  provide  a  base  for  optimistic  conclusions. 
They  demand  a  refocusslng  of  the  role  of  the  management  scientist  and  in  their 
very  criticisms  provide  pointers  as  to  what  that  role  should  be.   The  aim  in 
the  rest  of  this  paper  is  to  define  that  role,  based  both  on  conclusions  that 
can  be  synthesized  from  the  fragmented  exploratory  research  of  the  past  few 
years  and  on  the  equally  fragmented  beliefs  and  behaviors  of  effective  imple- 
menters  in  organizations.   The  main  intention  in  the  illustrations  made  so  far 
is  to  suggest  that  the  central  -  and  in  many  ways  simple  -  aspect  of  that  role 
is  a  clinical,  diagnostic  approach  to  implementation,  the  ability  to  assess 
the  full  organizational  and  management  'reality'  and  to  adapt  formal  design 


and  technique  to  it.   OR  graduates,  trained  in  a  tradition  that  is  explicitly 
rationalisitic,  technical  and  normative,  too  often  lack  that  ability,  or 
perhaps  simply  lack  an  awareness  of  its  relevance  so  that  the  ability  remains 
dormant  rather  than  absent.   In  some  ways,  redefining  one's  role  from  being 
a  designer  to  becoming  an  implementer  of  models  and  systems  will,  in  itself, 
make  those  latent  abilities  manifest, 
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actor'  Research  on  Implementation 

Having  recommended  this  shift  in  perspective,  we  have,  alas,  very  little 
conventional  wisdom  to  pass  on  to  the  would-be  implementer.   At  the  start  of 
this  paper  a  deceptively  simple  question  was  posed: 

"What  are  the  factors  that  enhance  the  likelihood  of  successful 
implementation? " 
A  recent  paper  by  Ginzberg-'--'-  that  surveys  the  efforts  to  answer  this  question 
finds  astonishingly  fragmented  and  even  contradictory  answers.   The  paper 
dissects  14  'Factor'  studies,  all  of  which  are  extensive,  well-researched 
and  Insightful,  so  that  Ginzberg  is  in  no  way  jousting  with  straw  men. 12   it 
identifies  140  distinct  factors  that  are  reported  as  having  a  significant  in- 
fluence on  the  likelihood  of  success  in  implementation:   Of  these  only  15  (11%) 
appear  in  3  or  more  of  the  14  studies  and  102  (73%)  are  reported  in  only  one 
study.   Table  2  shows  the  breakdown  of  the  140  factors: 

Table  2   Breakdown  of  Factors  Reported  in  14  Studies  (Ginzberg) 

140  Total  Factors 

102  (73%)    reported  in  1  study  only 

23  (16%)    reported  in  2  studies 

12  (09%)    reported  in  3  studies 

2  "     "  4  studies 

1  I.     II  5  studies 

Factors  reported  in  4  studies: 

a)  "well-defined,  measureable  objectives" 

b)  "complexity  of  techniques  and  models" 

Factor  reported  in  5  studies: 

c)  "top  management  support" 

Only  three  factors  appear  to  have  any  broad  empirical  support.   In  some 
cases  factors  found  to  correlate  with  particular  patterns  of  success  or  failure 


in  implementation  are  hard  to  interpret.   For  example,  Hervey  •'-^  finds 
"well-defined,  measureable  objectives"  to  be  of  substantial  impact  while 
Dickson  and  Powers-'-^  report  it  as  having  no  dlscemable  influence  using 
any  of  the  four  measures  of  "success"  they  employed.   Smith  et  al-'-^  find  a 
moderate  effect  and  Carter  et  al-'-",  in  a  very  ambitious  study,  find  a  very 
large  impact.   This  lack  of  consensus  is  not  at  all  unusual  in  an  immature 
field  of  research  (or  in  mature  ones,  as  the  recent  history  of  economics 
indicates)  but,  of  course,  it  hinders  the  development  of  prescriptive  tech- 
niques.  At  best,  our  conventional  wisdom  about  the  factors  affecting  imple- 
mentation success  are  those  shown  in  Table  3  and  even  this  is  tentative. 


Tab le  3  The  Conventional  Wisdom  on  Implementation 

'top  management  support" 

'a  clear  felt  need  by  the  client" 

'an  immediate,  visible  problem  to  work  on" 

'early  commitment  by  the  user  and  conscious  staff  involvement" 

'a  well-institutionalized  OR/MS  group." 

Some  of  these  may  also  be  hygiene  factors  in  Herzberg's  sense  of  the  term-'-'^; 
without  top  management  support,  for  instance,  a  project  faces  major  difficul- 
ties, but  having  that  support  may  be  of  little  direct  help. 

The  factor  research  is  less  than  the  sum  of  its  parts.   While  it  has 
isolated  at  least  some  of  the  clusters  of  variables  relevant  to    implement- 
ation, it  has  not  shown  their  interrelations,  has  not  provided  the  maps 
necessary  for  understanding  the  dynamics  of  the  process.   Too  often,  its  find- 
ings are  merely  correlative.   For  example,  the  Northwestern  School,  under 
various  permutations  of  Neal,  Radnor,  Rubinstein  and  colleagues^S,  have  pro- 
vided in-depth  longitudinal  studies  of  the  organizational  correlates  of  success- 
ful OR/MS  implementation;  these  have  used  large,  heterogeneous  samples  over 
a  long  time  period  and  are  clearly  among  the  most  scrupulous,  insightful  and 
reliable  empirical  analyses  so  far  available.   This  research  has  provided  some 
especially  valuable  conclusions  about  the  life  cycle  of  OR/MS  groups  and 
their  activities.^"   Even  here,  though,  the  studies  generally  allow  only  de- 
scriptive post  hoc  reconstructions  with  little  development  of  prescriptive 
techniques  in  that  they  often  focus  on  what  are,  at  best,  semi-controllable 
variables,  such  as  the  value  to  the  OR/MS  group  of  a  formal  charter.  More 


importantly,  they  identify  associations  without  throwing  much  light  on  the 
causal  dynamics  of  the  underlying  process.   Bean,  Neal,  Radnor  and  Tansik 
(1973)  surveyed  108  companies  In  12  Industry  sectors,  with  10  to  15  projects 
in  each  company. '^^  They  examine  30  factors,  using  two  measures  of  "success": 

1.  the  percentage  of  initiated  projects  that  are  actually  completed 

2.  a  subjective  assessment  by  the  head  of  the  OR/MS  activity  of  his 
group's  overall  success. 

Of  the  thirty  factors  examined,  about  one-third  have  no  apparent  re- 
lation to  either  of  the  two  measures  of  success.   Table  4  summarizes  the  re- 
sults : 

Table  4  Bean  et  al  Summary  of  Significant  Factors 

Factors  correlating  with  success  measures 

1  2  3 

implementation        group  head's  both  rate  and 

rate  overall  assessment         overall  assessment 

Positive 

Correlation        10  10  7 

Negative 

Correlation        4  2  0 


The  factors  positively  correlated  with  both  measures  of  success  are: 

1.  management  support  for  the  MS  approach  and  the  technical  group 

2.  top  management  interest  and  involvement  in  projects 

3.  the  proportion  of  the  MS  group  leader's  time  spent  on  implementation 

4.  the  level  of  the  MS  group  leader  within  the  organizational  hierarchy 

5.  the  formality  of  the  MS  group  (including  an  organizational  charter) 

6.  the  size  of  the  MS  group  in  relation  to  the  size  of  the  organization 

7.  the  availability  of  data  and  information  relevant  to  the  problem  situation 

One  factor,  "post-project  evaluation  audit"  is  positively  correlated  with 
the  rate  of  project  implementation,  but  not  with  overall  perceived  success. 
It  is  difficult  to  assign  a  meaning  to  this  unless  one  examines  the  dynamics 
of  the  process  it  reflects;  presvnnably  the  post-project  audit  relates  back  to 
other  procedures  in  planning  and/or  project  management  that  are  the  causal 


Influence.   The  problem  this  example  illustrates  is  a  common  one  in  Factor 
rpHearcli,  a  haHtcally  atatic  analysis  of  a  dynamic  multidimensional  process, 
a  HiiapHliol  of  altltudlnal  or  stnu;tural  variables  at  a  particular  point  in 
time.   The  nature  of  the  process  is  Inducted  by  clustering  and  correlating 
those  variables. ^1 

The  conclusion  to  be  drawn  from  the  Factor  research  as  a  whole  is  not 
so  much  that  we  have  no  basis  for  a  conventional  wisdom  as  that  there  are 
obviously  few  absolutes.   The  contradictions  and  lack  of  overlap  Ginzberg 
found  in  the  fourteen  studies  he  assessed  suggest  that  implementation  is  a 
contingent  process.   The  panel  of  Through  a  Glass  Darkly  seem  to  feel  this, 
too,  in  that  they  criticize  management  scientists  for  not  adjusting  to  the 
particular  demands  of  the  manager's  situation.   The  term  'contingency  theory' 
is  a  major  trend,  even  a  fad,  in  behavioral  areas  of  organizational  research. 22 
It  neatly  cuts  through  some  Gordian  knots  by,  for  instance,  conveniently 
accepting  such  contradictions  as  those  in  Ginzberg 's  survey  as  due  to  some 
'background  features'  of  the  situation  (this  Is  Nadel's  phrase  in  a  discussion 
of  some  similar  problems  to  the  ones  discussed  here,  in  comparative  research 
in  political  science23) .   Implementation  is  then  viewed  as  a  function  of  many 
I      forces,  the  strength  of  which  varies  according  to  context  -  that  is,  "it  all 
depends".  However,  this  contingency  approach  can  raise  more  issues  than  it 
resolves,  since  of  course  the  key  problem  is  to  identify  just  what  it  all 
depends  on  and  how.   This  requires  metatheory,  a  theory  of  contingency.   Of 
course,  it  also  implies  that  regardless  of  our  ability  to  provide  this  meta- 
theory, the  implementer  can  be  effective  only  if  he  can  map  the  contingencies 
of  the  situation,  that  indeed  there  are  no  absolutes  to  guide  him  and  that 
his  techniques  must  be  tailored  to  his  clinical  assessment  of  their  context. 

A  Conceptual  Map  of  the  Implementation  Process 

A  clinician  needs  a  checklist  of  symptoms.  The  next  section  of  this 
paper  presents  a  simple  conceptualization  of  the  implementation  process; 
this  is  not  intended  as  a  'theory'  of  implementation  but  as  an  elementary 
and  general  map  that  can  allow  the  implementer  to  diagnose  and  take  action. 
The  context  of  implementation  is  a  complex  fusion  of  contingent  variables 
and  a  key  step  in  managing  the  process  is  simply  to  identify  the  key  Issues 
and  constraints  and  determine  their  relative  influence. 


Figure  1  represents  the  contingent  variables  in  terms  of  a  literal, 
Lewinlan  force  field.  24  jj^g  uni-directional  solid 

arrowH  represent  'forces';  for  example,  the  characteristics  of  the  problem. 
Its  structurabillty ,  urgency  etc.,  exert  a  force  that  influences  the  direction 
of  the  implementation  process.   If  one  thinks  of  that  outcome  force  as  aiming 
towards  a  neon-lit  gateway  labelled  "Success"  then  each  force  in  the  field  can 
either  divert  the  implementation  process  or  help  point  towards  success.  (Or 
as  the  dotted  lines  show,  toward  disaster). 

[Figure   1] 

IMPLEMENTATION  AS  A  FORCE  FIELD 
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This  schematization  is  obviously  an  oversimplification  and,  even  on 
its  own  terms,  is  incomplete.   In  some  sense  it  merely,  like  the  factor  re- 
search, clusters  variables,  adding  in  the  notion  of  directional  strength 
and  influence.   The  key  feature  to  be  stressed,  though,  is  that  many  of  the 
potential  forces  are  not  acting  in  a  particular  context  (while  in  others 
they  may  be  of  dominating  impact).   For  example,  Figure  2   (below)  character- 
izes a  hypothetical  situation  in  which  a  chemicals  company  requires  a  one-shot 
production  planning  model  for  scliedullng  a  new  product.   The  problem  is  a 
complex  one,  involving  a  variety  of  constraints;  the  required  data  is,  however, 
available  and  there  seem  to  be  a  niamber  of  applicable  standard  optimization 
techniques.   The  OR/MS  group  is  well-institutionalized,  though  the  manager 
for  whom  the  model  is  to  be  designed  has  had  only  intermittent  contact  with 
the  group.   He  is  an  engineer  with  a  fairly  strong  mathematical  background. 
Finally,  the  problem  has  very  few  interdepartmental  implications. 


[Figure  2] 
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In  LIiIh  h  1  tu/il  Ion ,  tlie  rt-levaiit.  vurlablt-H  combine  to    facilitate  ImpJfment- 
atlon.   There  are  only  u  few  forces  (and  virtually  no  organizational  forces) 
each  of  which  tends  towards  the  right  direction;  for  example,  the  manager's 
training  and  experience  are  compatible  with  the  analytic  approach  and  there  are 
no  pressures  from  organizational  politics.   The  problem,  too,  is  a  textbook 
case,  optimization  of  a  well-defined,  well  structured  production  process. 

If,  however,  the  fiction  is  only  slightly  changed  and  we  assume  that  the 
manager  is  hostile  to  OR/MS  and  a  'seat-of-the-pants-and-proud-of-it '  type, 
then  the  outcome  of  the  force  field  is  very  different  and  the  implementation 
effort  is  very  likely  to  be  a  failure.   The  mode  of  problem-solving  implicit 
in  an  optimization  model  is  alien  to  this  manager;  he  is  unconvinced  of  its 
value  and  validity,  lacks  the  ability  to  critique  it  and  is  very  probably 
personally  threatened  by  it.   If,  but  only  if,  the  management  scientist  diag- 
noses this  force  field  he  can  almost  certainly  adjust  the  forces  through  his 
own  implementation  strategy.   He  can,  for  example,  spend  substantial  effort 
building  a  conceptual  line  of  credit  with  the  manager,  starting  from  a  very 
simple  simulation  model  that  the  manager  can  explore   to  better  define  terms, 
constraints  and  alternatives;  the  manager  can  more  easily  validate  the  out- 
puts of  such  a  model  and  thus  build  trust  and  confidence  in  the  management 
scientist  as  a  basis  for  later  accepting  a  more  complex  optimization  model. 
In  terms  of  the  force  field  representation,  the  implementer*8  strategy  in- 
volves strengthening  or  weakening  existing  forces  or  adding  a  new  countering 
force;   this  adjustment  is  represented  by  Figure  3  (b) . 

Figure  3 
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A  Clinical  Strategy 

Obviously,  the  schematization  shown  in  Figure  3  does  not  define  the 
exact  nature  of  the  tmplementer 's  strategy.  It  does,  however,  make  clear 
the  Immense  risk  involved  in  not  identifying  relevant  forces.  A  clinical 
diagnosis  prior  to  any  design  of  the  model  or  system  to  be  implemented  will 
at  least  give  the  implementer  a  stronger  hand  to  play.  Clearly,  even  with 
such  a  diagnosis,  there  is  always  a  chance  that  the  user  will  still  reject 
the  result,  whatever  the  implementer  does.  None  the  less,  the  implementer 
can  at  least  develop  a  conscious  strategy  based  on  risk  rather  than  on  good 
faith  and  blithe  ignorance  of  the  hidden  undercurrents  of  a  situation. 
Implementation  is  too  often  the  management  of  unanticipated  consequences; 
in  the  situation  outlined  in  Figure  3  above,  the  management  scientist,  if 
he  designs  his  model  without  identifying  and  adjusting  to  the  relevant  con- 
tingencies, will  later  have  to  become  a  firefighter.  Firefighting  is  expen- 
sive and  generally  ineffectual. 
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This  redefinition  of  the  implementer 's  role  from  designer  to  clinician 
and  facilitator  is  really  very  simple.   It  may  not  require  much  new  knowledge, 
merely  a  recognition  and  assimilation  of  relevant  knowledge.   For  example, 
a  number  of  researchers,  including  the  author,  have  focused  on  the  issues 
sketched  out  in  the  hypothetical  situation  in  Figure  3,  the  impact  of  cogni- 
tive style  on  the  willingness  to  adopt  analytic  methods: 

"...such  aids  (analytic  models)  must  be  designed  to  amplify  the 
user's  problem-solving  strategies.   Thus  it  seems  that  the  central 
factor  in  determining  whether  a  manager  will  use  a  model  to  reach 
a  decision  is  the  extent  to  which  it  'fits'  his  style  of  thinking 
...If  the  manager  and  thp  management  scientist  can  recognize 
first  that  each  has  a  different  cognitive  stvle,  and  thus  a 
different  way  of  solving  the  same  problem,  then  their  dialogue  seems 
more  likely  to  bear  fruit."  (McKenney  and  Keen)^^ 

A  difficulty  with  this  claim,  even  if  valid,      is  that  cognitive  style  is 

only  one  of  many  interacting  variables.   It  seems  better  to  modify  the  argument 

and  to  speak  of  cognitive  style  as  a  potential  constraint  or  facilitator  in 

implementation;  it  is  not  always  relevant  to  a  particular  situation,  but  the 

management  scientist  must  diagnose  when  it  is  or  la  not  relevant,  tf  he  Is  to 

meinage  the  implementation  process. 

The  technical  and  normative  traditions  of  management  science  have  often  delib- 
erately ignored  this  need.   As  Starr  points  out  in  "The  Politics  of  Management 
Science",  the  analytic  view  of  Truth  is  '0,1'  while  the  manager's  'truth' 
always  has  a  political  context;  he  argues  that  the  analyst  must  also  be  a 
'political  scientist'  who  includes  managerial  attitudes  in  his  choice  of  a 
solution,  an  argument  parallel  to  the  one  made  here. 26  Starr's  example  is 
especially  relevant  in  that  some  management  ecientlHts  conHcloualy  chooHi*  to 
ignore  political  forces  even  though  they  are  readily  apparent.   Gibson  and 
Hammond  provide  a  fairly  typical  example  of  this. 2'   They  describe  a  large- 
scale  project  in  the  corporate  planning  department  of  a  large  manufacturing 
company.   Progress  over  the  first  three  months  was  excellent  and  the  staff 
viewed  it  as  a  very  effective  venture.   It  was,  however,  abruptly  terminated. 
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The  model  built  by  the  staff  was  technically  well-designed  and  the  logisitical 
problems  were  handled  well.   The  economic  issues  involved  were  understood  by 
both  the  design  group  and  the  planning  staff.   Moreover,  the  operational  char- 
acteristics of  the  model  were  clearly  suited  to  the  planners  and  analysts  who 
used  its  outputs  in  preparing  their  recommendations.   Their  report  was  skill- 
fully presented  and, indeed,  very  well-received  by  Mr.  Cabot,  the  vice-president 
who  had  commissioned  the  model.   Despite  all  this,  the  implementation  effort 
had  no  impact  on  top  management's  decisions,  except  to  raise  their  anger.   Un- 
fortunately, Mr.  Cabot  has  aspitations  for  succeeding  to  the  recently  vacated 
presidency  of  the  company  and  was  using  the  modelling  project,  as  the  design 
team  were  almost  gleefully  aware,  as  a  way  to  'preempt  other  departments  in 
the  planning  process  and  later  to  shine  in  front  of  the  Board'  by  presenting 
the  very  impressive  results  of  the  modelling  project.   He  was  shot  down  and 
the  corporate  planning  department  bore  the  brunt  of  his  dismay  and  top  manage- 
ment's irritation. 

The  key  symptom  in  this  project,  what  Gibson  and  Hammond  call  the 
'informal-social'  contingencies,  was  known  and  ignored.   The  design  group 
presumably  had  not  thought  through  the  direct  relevance  of  such  outside,  non- 
technical forces  for  their  own  actions.  The  political  dimension  is 
not  always  relevant  to  an  implementation  effort;  here  it  was,  and  the  design 
team  should  have  recognized  it  as  being  so.   To  explain  the  failure  of  the 
project  as  being  due  to  non-rational  'politics'  is  not  to  excuse  it.   The  lack 
of  a  clinical  definition  of  their  role  led  them  into  a  venture  they  could  not 
control  and  the  outcome  was  once  again  one  of  unanticipated  consequences. 

Of  course,  political  undercurrents  in  an  organization  are  not  easy  to  pick 
out  at  times   In  particular,  hidden  agendas  are  intendedly  secret.   This  fact, 
though,  reinforces  the  need  for  a  clinical  perspective.   Gibson  points  out  in 
a  study  of  a  large-scale  project  in  a  bank  that  the  analyst  will  generally  be 
given  an  overrationalized  explanation  of  organizational  practices  and  that  the 
researcher  (implicitly,  too,  the  practicioner)  must  consciously  try  to  get  be- 
neath the  surface. 28 

Implementation  as  the  Management  of  Change 

The  arguments  made  so  far  justify  a  particular  focus  on  implementation. 
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Obviously,  however,  a  more  detailed  framework  is  needed  to  extend  that  focus 
to  provide  specific  techniques  for  managing  implementation.  Perhaps,  given 
the  exploratory  nature  of  research  to  date,  it  is  premature  to  suggest  any 
particular  framework.   None  the  less,  from  recent  studies  and  from  the  less 
formalized  perceptions  of  a  number  of  experienced  implementers ,  it  does  seem 
that  viewing  the  implementation  process  in  terms  of  a  social  change  process 
provides  a  paradigm  that  is  both  conceptually  rich  and  practical  in  its  im- 
plications.  That  paradigm  is  especially  consistent  with  the  main  theme  of 
this  paper  in  that  it  centers  on  the  role  of  the  change  agent  -  the  implementer 
-  as  a  clinician,  a  'process  consultant'  (in  Schein's  phrase) 29  and  a  facili- 
tator. 

We  often  fairly  glibly  talk  about  implementation  as  an  organizational 
change  process  and  the  management  scientist  as  a  change  agent,  without  paus- 
ing to  examine  the  implications  of  interpreting  that  literally.   There  has 
been  an  immense  variety  of  work  throughout  the  social  sciences  on  the  dynamics 
of  planned  change  and  this  work  shows  a  remarkable  unity,  whether  its  speci- 
fic topic  is  the  training  of  Benedictine  novices  (Erlksen)30,  brainwashing  of 
POW's  in  Korea  (Schein)   ,  organization  change  (Bennis)^^^  or  group  dynamics 
(Cartwright)33.   On  the  whole,  planned  change  has  ignored  the  technical  and 
technological  aspects  of  social  change,  but  its  Insights  still  hold  extremely 
well  in  the  technical  world  of  OR  and  MIS. 

The  most  basic  framework  is  Lewin's  (expanded  by  Schein)  which  views 
change  as  a  three-stage  process: 

Figure  4 

The  Lewin-Schein  Model  of  Chnage 

Unfreezing 

i 
Changing 

i 

Re free zing 


Each  of  these  stages  must  be  vjorked  through  if  a  change  program  16  to  be 
effective.   Schein  defines  the  stages: 

"1.  Unfreezing:  an  alteration  of  the  forces  acting  on  the  individual 
such  that  his  stable  equilibrium  is  disturbed  sufficiently  to 
motivate  him  and  make  him  ready  to  change;  this  can  be  accomplished 
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either  by  increasing  the  pressure  to  change  or  by  reducing 
some  of  the  threats  or  resistances  to  change.... 

2.  Changing;  the  presentation  of  a  direction  of  change  and 
the  actual  process  of  learning  new  attitudes 

3.  Refreezing;  the  integration  of  the  changed  attitudes  into 
the  rest  of  the  personality  and/or  into  ongoing  significant 
emotional  relationships.  "3'4 

Schein's  description  maps  well  onto  OR/MS  implementation  ('implementation' 
here  includes   all  three  stages  of  course;  the  technical  tradition  that  the 
"Through  a  Glass  Darkly"  panel  complained  of  views  the  middle  stage,  'Changing' 
or  'Action',  as  equivalent  to  implementation  and  the  responsibility  for  the 
preceding  and  succeeding  processes  as  being  the  organization's  not  the  designer's) 
The  Unfreezing  stage  perhaps  explains  much  of  our  conventional  wisdom.   "Top 
management  support",  "a  felt  need  by  the  client"  and  "an  immediate,  visible 
problem  to  work  on"  (See  Table  3  )  ,  factors  that  facilitate  implementation, 
all  relate  to  the  need  that  there  be  motivation  and  momentum  for  change.   Alter 
reports,  in  a  detailed  study  of  56  computer  systems  and  models,  that  systems 
that  were  'sold'  to  the  user  by  the  technical  group  were  rarely .  successful. -^5 
Change  needs  to  be  self-motivated  and  the  client-system  must  take  responsibil- 
ity for  and  be  committed  to  the  change  program  (for  a  detailed  discussion  of 
this  aspect  of  Unfreezing  see  Bennis^^).   "Resistance  to  change"  reflects  a 
lack  of  Unfreezing;  such  resistance  is  often  assumed  by  the  analyst  who  en- 
counters it  to  be  a  pathological  rejection  of  Truth,  Beauty,  and  Integer  Pro- 
gramming.  The  Lewin-Schein  model  highlights  the  fact  that  this  resistance 
may  be  a  reasonable  response  from  a  system  in  equilibrium  that  feels  no  moti- 
vation to  adjust.   The  currency  of  management  science  is  Change  and  analytic 
specialists  often  work  from  the  viewpoint  that  change  is  generally  desirable 
in  itself.   Since,  however,  change  programs  are  almost  certain  to  be  ineffect- 
ual unless  the  Unfreezing  stage  has  been  worked  through,  the  management  scien- 
tist must  take  on  as  part  of  his  function  the  creation  of  a  climate  for  change. 
Sometimes  this  climate  builds  itself  -  an  urgent  problem  involving  substantial 
costs  or  profits  can  unfreeze  a  manager  very  quickly. 
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An  unfrozen  system  will  be  homeostatic,  trying  to  dampen  change;  once 
unfrozen,  however,  that  system  must  change,  must  find  a  new  equilibrium.   By 
working  to  unfreeze  an  organization,  the  implementer  can  coopt  its  energy 
and  momentum.   In  marketing  terms,  one  cannot  sell  change  but  must  make  the 
consumer  want  to  buyj  the  selling  effort 

must  focus  on  building  a  'felt  need'  for  which  w.e  happen  to  have  the  solution; 
the  product  itself  should  not  even  be  mentioned  until  the  consumer  is  Unfrozen. 

The  Refreezing  stage  explains  many  semi-successes  in  management  science 
applications,  projects  which  have  an  apparently  successful  outcome  but  which 
lose  impetus  and  sink  into  oblivion  when  their  sponsor  or  designer  leaves  the 
scene.   The  system  in  that  situation  is  not  self-sustaining  but  maintained  by 
the  enthusiasm  and  effort  of  a  single  individual.   Change  must  be  institution- 
alized by  the  building  of  a  new  and  stable  equilibrium  that  supports  the  change. 
Again,  there  are  clear  implications  for  the  management  scientist  in  building 
systems  that  are  intended  for  more  than  one-shot  use;  he  must  make  sure  that 
the  change  is  truly  'complete',  that  the  system  is  embedded  in  the  organization. 
This  may  require  training,  the  assignment  of  a  systems  'manager'  within  the 
user  department  or  even  new  operating  procedures.   In  particular,  the  change 
is  not  complete  if  the  system  is  not  consonant  with  the  organization's  control 
and  reward  systems.   Alter  reports  that  many  of  the  systems  he  examined  had 
difficulties  obtaining  the  necessary  input  data  if  that  data  was  not  processed 
routinely  by  the  department  responsible.-^ 

The  dynamics  of  the  Lewin-Schein  model  are  complex  and  only  casual  il- 
lustrations have  been  given  here.   Sorensen  and  Zand  used  the  model  in  a  study 
of  280  management  science  projects. ^8  Their  results  suggest  that  the  frame- 
work has  substantial  explanatory  power  and  that  the  Refreezing  stage  seems 
most  critical  in  explaining   implementation  success. 

A  Strategy  for  Managing  Change 

Regardless  of  its  value  as  a  basic  paradigm,  however,  the  raw  Lewin-Schein 
model  lacks   detail.   Kolb  and  Frohman's  model  of  the  consulting  process  in 
oreanizational  development  extends  the  frame  to  provide  a  rich  normative  base39 
(Organizational  Development  is  to  Planned  Change  what  Management  Science  is  to 
Operations  Research) .   Urban  used  the 
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Kolb-Frohman  model  in  his  own  implementation  of  marketing  models;  his  paper 
"Building  Models  for  Managers"  (Interfaces  1974)^'^  discusses  it  in  substantial 
detail,  relating  it  directly  to  the  technical  minutiae  of  a  modelling  project. 

Like  Lewin  and  Schein,  Kolb  and  Frohman  argue  that  effective  organization- 
al change  involves  working  through  a  series  of  stages.   The  seven  stages  they 
define  are  presented  in  terms  of  the  consultant's  actions.   Figure  5  shows 
the  Kolb-Frohman  model  and  Urban 's  reformulation  of  it  in  the  context  of 
implementing  data-based  marketing  models. 


[Figure   5] 
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'Action'  of  course  is  not  implementation,  anymore  than  getting  a  model 
up-and-running  guarantees  its  use.   The  central  Action  stage  must  be  preceded 
by  the  establishment  of  a  contract  for  the  venture  (this  is  an  elaboration 
of  Unfreezing)  and  followed  by  Evaluation  and  Termination,  where  the  system 
is  linked  into  the  ongoing  organizational  activities. 

SCOUTING  is  the  stage  least  directly  relevant  to  implementation  (though 
certainly  relevant  to  consulting  in  the  management  science  area) .   It  involves 
matching  the  capabilities  of  the  consultant  with  the  needs  of  the  client- 
organization;  this  implies  avoiding  what  Heany  has  called  "Have  technique, 
will  travel",  in  which  every  problem  is  solved  by,  say,  linear  programming. 
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ENTRY  Involves  ensuring  legitimacy  for  action:  defining  the  problem-situation, 
the  nature  of  a  solution,  criteria  for  evaluation  and  the  allocation  of 
responsibilities  and  resources,  even  if  only  at  a  general  level.   In  arguing 
earlier  that  the  management  scientist  should  define  his  role  as  being  essen- 
tially clinical  and  facilitative,  many  points  were  made  that  can  be  more  ex- 
plicitly captured  in  terms  of  this  Entry  stage.   Entry  requires  subtle  skills 
and  in  many  instances  far  more  time  and  effort  than  any  other  aspect  of  im- 
plementation (see  Urban 's  case  study:   A  Family  Planning  System  which  elabor- 
ates on  the  relative  effort  involved  in  Entry'^^)  .   Far  too  often  the  analyst 
responds  to  the  pressure  for  visible  results  and  gets  going  on  formalizing 
the  model  or  system,  leaving  the  'people'  issues  to  be  sorted  out  later.   How- 
ever, most  of  the  critical  decisions  are  made  at  Entry,  particularly  in  com- 
plex projects  which  involve  an  innovative  system  with  many  inputs,  users  and 
applications.   Moreover,  it  is  in  Entry  that  the  client's  expectations  are 
set;  to  some  extent  implementation  i£  the  management  of  expectations  -  many 
failures  occur  not  because  a  'good'  model  was  not  delivered,  but  because  the 
'right'  one  was  not  or  because  the  user  had  excessively  high  expectations  which 
led  him  to  enthusiastically  support  the  effort  but  which  could  never  be  met 
in  practice. 

Lucas  provides  an  insightful  case  study  of  how  the  Entry  stage  should  be 
managed.   He  describes  a  technically  simple  MIS  built  for  the  United  Farm 
Workers  Union  (the  simplicity  of  the  system  meant  of  course  that  Action  was 
brief  and  easily  handled)^^.   Lucas  and  his  co-workers  diagnosed  the  state  of 
the  client-system  and  found  that  the  long-service  older  professional  core  of 
the  UFW  would  need  careful  Unfreezing,  that  while  they  might  not  actively  re- 
sist the  change  in  operations  and  style  implicit  in  the  system,  they  were 
clearly  not  motivated  to  accept  it.  The  MIS  team  arranged  a  retreat  at  which 
they  presented  a  simple  design  plan  with  the  statement  that  they  would  feel 
unhappy  if  at  least  half  the  plan  were  not  rejected  and  redefined  by  the  UFW 
personnel.   In  this  way,  the  criticisms,  restatements  and  definitions  provided 
by  the  UFW  group  shifted  the  change  program  from  being  externally  brought  in, 
towards  being  self-motivated  and  under  their  control  and  initiation.   As  a 
tactic  for  unfreezing  this  approach  seems  generally  valuable.  Urban  similarly 
designed  a  simple  'Mod  1'  model  for  a  family  planning  agency. ^-^  This  model 
was  overgeneral  and  incomplete;  by  getting  the  user  group  to  determine  whether 
the  errors  in  output  were  due  to  faults  in  the  model  or  to  some  aspect  of  the 
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wider  environment  that  the  user  group  had  not  identified.  Urban  threw  the 
responsibility  for  developing  a  better  model  onto  the  users,  connnitting  and 
involving  them. 

Vertinsky,  Barth  et  al^^  at  the  University  of  British  Columbia  have  been 
directly  involved  in  a  number  of  implementations,  working  explicitly  from  this 
approach.   They  similarly  stress  the  critical  importance  of  Entry  and  Unfreez- 
ing.  From  these  and  similar  studies  it  seems  possible  to  specify  the  issues 
in  Entry  -  and  implicitly  the  responsibilities  of  the  implementer:   successful 
resolution  of  Entry  requires: 

1)  a  felt  need:   a.  the  implementer  must  make  sure  that  the  problem 

to  be  worked  on  is  visible  and  seen  as  relevant 

b.  he  must  make  sure  that  the  'client'  has  a  motive 
and  commitment  for  action 

2)  a  definition  of  goals  in  operational  terms 

a.  what  are  the  criteria  for  'success'? 

b.  what  are  the  priorities  and  tradeoffs? 

c.  what  'key'  indicators'  can  be  used  to  measure 
progress  and  accomplishment? 

3)  a  contract  for  change;  a  'deal'  between  designer  and  client  in  which 
the  following  is  established 

a.  'trust'  -  personal,  professional  or  political 

b.  mutual  understanding  (cf.  Churchman  and  Scheinblatt) 

c.  mutual  respect  for  each  other's  style,  investment 
and  needs 

d.  realistic,  mutual  expectations 

4)  diagnosis  and  resolution  of  resistance  to  change  by: 

a.  including  users  as  well  as  the  client  in  implementation 
(Alloway  makes  the  point  that  the  designer  often  ig- 
nores the  secondary  users,  groups  who  are  indirectly 
but  substantially  affected  by  the  system,  by  for  ex- 
ample, being  responsible  for  collecting  particular 
input  data)  ^^ 

b.  recognizing  that  resistance  is  a  signal  to  be  responded 
to,  not  a  pathology  to  be  eliminated  by  fiat,  power 

or  endplays 

5)  initial  allocation  of  resources  and  responsibilities 

a.  meaningful  user  involvement 

b .  the  development  of  a  team 
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This  list  is  arid  shorthand  for  a  complex  process  (see  Ginzberg  [1975] 
and  Urban   for  further  discussions  of  Entry).   It  is  worth  mentioning  in 
passing,  that  the  characteristics  and  behavior  necessary  in  the  implementer 
for  the  Entry  process  to  be  successful  correspond  closely  to  Schein's  defin- 
ition of  a  'process  consultant'  who  must  know  "how  to  diagnose  and  establish 
helping  relationships,'"^'  who  is  an  expert  at  getting  a  'feel'  for  a  situation, 
at  the  same  time  being  able  to  get  people  working  together  and  goals  and  pro- 
cedures operationalized. 

Entry  also  provides  the  bases  for  EVALUATION.   In  many  projects  no  real 
definition  of,  or  criteria  for  evaluating,  success  is  ever  made.   The  venture 
was  justified  on  the  basis  of  the  standard  polite  fictions  of  saving  $X  on 
clerical  personnel  and  increasing  work  load  by  Y% .   The  real  impetus  for  the 
project  may  remain  a  hidden  agenda:  the  pponsor's  belief  that  the  system  will 
lead  to  'better'  decision-making.   After  the  event,  when  the  development  costs 
and  time  are  their  customary  large  fraction  over  budget,  it  is  too  late  to 
open  up  the  hidden  agenda  and  argue  that  the  system  is  a  'success'.   Evaluation 
of  a  completed  project  can  really  be  made  meaningful  only  by  formalizing, 
before  the  system  is  even  designed,  a  'deal'  or  'contract'  which  includes  some 
definition  for  success;  this  would  require  specifying  'key  indicators',  vari- 
ables that  the  consultant  and  client  group  agree  can  be  used  as  surrogate 
measures  for  'better  decision-making'.^*  Evaluation  cannot  be  a  post  facto 
audit  .   In  an  ongoing  study,  Ginzberg  has  identified  a  number  of  cases  where 
even  after  the  event,  the  designer  and  user  had  very  different  perceptions 
of  the  intent  of  the  system  and  the  degree  to  which  it  was  successful'^9  j 
'success'  is  again  contingent  on  intent  and  the  responsibility  of  the  manage- 
ment scientist  is  to  ensure  that  there  is  a  joint  resolution  of  that  contingency. 
Radnor,  Tansik  and  Rubens tein,  whose  approach  to  implementation  is  much  more 
analytic  and  technical  than  the  one  proposed  here,    argue     in  a  similar 
direction^O.  j-^ey  point  to  the  relative  difficulty  of  measuring  the  results 
of  OR/MS  activities  and  strongly  suggest  that  the  predesign  stage  (approxi- 
mating Entry)  is  where  the  PEC,  Project  Evaluation  Criteria,  must  be  established. 
Only  then  can  non-operational  goals  be  formalized  and  any  incongruence  between 
the  client  and  designer,  in  terms  of  goals  and  expectations,  be  resolved. 
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Determining  the  Criteria  for  'Success' 

A  central  issue  in  implementation  research,  hinted  at  earlier  but  not  dis- 
cussed directly,  focuses  on  the  question  of  what  is^  success;  Dickson  and 

Powers  use  four  measures,  which  have  very  low  intercorrelations  and  their  ex- 
perience seems  fairly  typical-* •'-•   There  is  a  tendency  to  equate  success  with 

use,  partly  since  terminal  hours  per  month  is  an  easily  obtained  metric. 

However,  there  are  some  instances  where  a  successful  implementation  is  one 

where  the  analyst  helps  a  manager  to  understand  his  problem-environment 

better,  to  a  degree  that  he  may  then  say  'that's  a  lousy  model'  even  if  the 

model  was  built  to  his  specifications.  Management  scientists  too  often  think 

of  a  model  or  system  as  a  product;  'success'  then  means  providing  the  best 

product,   sports  coupe  with  all  options  ,  even  where  the 

manager  really  wants  cheap,  quickly-provided  transportation.   Of  all  the 

characteristics  that  seems  to  differentiate  effective  Implementers  from  the 

OR  graduates  lambasted  in  the  panel  discussion  quoted  earlier,  the  distinction 

CO 

between  a  Service  and  a  Product  orientation  seems  most  central.    Again, 
this  conclusion  needs  to  be  modified  in  terms  of  diagnosis;  there  are  occasions 
as  in  the  hypothetical  instance  of  a  one-shot  planning  model  discussed  earlier 
(see  Figure  2)  where  Entry  is  simple,  the  criteria  for  success  easily  identi- 
fied and  a  Product  definitely  required.   However,  in  the  example  following 
that  one,  where  the  user  is  assumed  to  be  hostile  to  the  analytic  approach, 
a  Product  role  on  the  part  of  the  analyst  virtually  guarantees  failure. 

Huysmans  provides  a  useful  taxonomy  of  'success '53;  he  defines  three 
'levels  of  adoption':  (a  fourth  level  has  been  added  by  this  author  to  include 
the  innovative  interactive  Decision  Support  Systems  described  by  Scott  Morton 
and  Gerrlty)54; 

1.  does  the  model  or  system  lead  to  management  action  (is  it  used?) 

2.  does  it  lead  to  management  change  (do  management  get  new  insights 
or  Information  or  adjust  their  decision  process?) 

3.  does  It  lead  to  recurring  use  of  the  OR/MS  approach? 

4.  does  it  lead  to  an  extension  or  redefinition  of  the  task  it  supports? 
Only  levels  1  and  2  can  be  evaluated  in  terms  of  the  use  of  the  system.   Success 
is  contingent  and  the  technical  features  of  the  system  will  be  very  different 
depending  on  which  level  is  assumed;  that  choice  must  be  made  before  the  sys- 
tem is  designed.   The  analyst's  own  view  of  his  role  Influences  his  ability 

to  select  a  level  that  is  congruent  with  the  clients  'needs',  the  organization's 
current  activities  and  capabilities,  etc.,  etc  -  once  again,  the  analyst  him- 
self must  identify   the  et  ceteras  for  this  particular  situation. 
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Underlying  the  recommendations  made  so  far  in  this  paper  is  a  more 
fundamental  Issue.   Every  management  scientist  has  an  implicit  model  of  the 
decision  process  that  he  uses;  generally  that  model  comes  from  the  Rational- 
istic tradition  that  underpins  the  analytic  disciplines.   That  tradition  is 
normative,  stressing  logic  and  method.   It  is  also  axiomatic  and  most  analysts 
ignore  that  fact.   The  axioms  of  one  discipline  may  be  the  hypotheses  of 
another;  for  example,  the  concept  of  utility,  which  is  axiomatic  to  economics 
and  decision  theory,  is  a  major  hypothesis  -  not  too  well  supported  experi- 
mentally -  in  cognitive  psychology.   The  point  is  critical;  managements dent- 
ists have  too  often  seen  the  analytic  approach  as  the  one  Right  Way  and  ele- 
vate the  formalization  and  structuring  of  problems  above  the  implementation 
of  effective  solutions  as  against  'correct'  or  'optimal'  ones.   They  tend 
to  disdain  the  way  in  which  managers  operate  and  to  lack  even  an  understand- 
ing of  what  that  way  is.   Few  management  scientists  are  at  all  familiar  with 
descriptive   theories  of  the  decision  process.   For  example,  Lindblom's  model 
of  'Muddling  Through'  in   political  science  shows   that  in   many 
instances  margin-dependent  choices  rather  than  formal  evaluation  of  outcomes 
can  be  a  highly  effective  way  of  dealing  with  complex  problems. 55  Lindblomian 
decision-makers  examine  only  the  alternatives  that  are  close  to  their  exper- 
ience; they  cannot  assess  the  utility  of  pomegranates  and  oranges  but  can  de- 
cide if  they  prefer  three  apples  to  the  two  oranges  they  have  now.   Management 
scientists  operate  from  their  implicit  model  of  decision-making;  it  Is  a 
powerful  one  but  it  does  not  reflect  the  actual  behavior  of  many  of  their 
clients  who  are  often  very  effective  decision-makers,  particularly  in  their 
ability  to  deal  with  problems  they  do  not  consciously  understand.   The  clini- 
cal facilitator,  even  when  he  aims  at  moving  a  manager  towards  the  Rational 
ideal,  will  recognize  where  the  manager  starts  from,  understand  the  dynamics 
of  his  response  and  respect  his  abilities.   Implementation  must  start  from 
this  understanding  and  the  implementer  must  include  in  his  body  of  knowledge 
descriptive  as  well  as  normative  theories  of  the  decision  process.   Minzberg, 
for  example,  shows  that  the  manager  lives  in  and  prefers  a  world  of  'Brevity, 
Fragmentation  and  Variety '56.   Knowledge  of  this  aspect  of  the  management 
reality  in  itself  enables  the  analyst  to  match  his  techniques  to  the  context. 
Schein  speaks  of  management  as  a  process  of  influence-*';  his  definition  applies 
directly  to  implementation. 


on:   The  Role  of  the  Implementer 
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A  role  is  mainly  a  set  of  expectations  about  how  to  behave.   In  general 
the  expectations  of  the  graduating  OR  or  MIS  specialist  have  been  that  his 
role  is  that  of  a  technician  and  that  any  difficulties  he  encounters  in 
getting  managers  to  make  use  of  the  tools  he  provides  comes  from  their  in- 
adequacies, not  his.   What  has  been  presented  in  this  paper  is  an  outline 
for  a  more  effective  role.   It  really  requires  little  new  knowledge,  only  small 
adjustments  of  attitude  which  lead  to  large  changes  in  outcome.   The  role 
of  'facilitator'  and  manager  of  change  is  in  some  ways  an  easier  one  than 
that  of  the  much-beleagured,  ever-struggling  Expert  in  an  alien  land.   This 
is  not  to  argue  against  technical  ability;  indeed,  the  argument  here  takes 
technical  skill  as  a  given.   However,  techniques  are  means  not  ends  and  must 
be  matched  to  context. 

It  is  convenient,  though  an  arbitrary  dichotomy,  in  concluding  this 
argument,  to  draw  a  distinction  between  Technician  and  Implementer. 


Locus  of  effort 

Output 

Attitude  towards 
Change  Process 

Main  skill  areas 

Assumptions  about  the 
decision  process 

Slogan 


TECHNICIAN 

DESIGN 

Product 

DIFFUSION  OF 
INNOVATION 

KNOWLEDGE 
TECHNIQUES 

ANALYTIC 
PRESCRIPTIVE 

"HAVE  TECHNIQUE.  WILL 
TRAVEL" 


IMPLEMENTER 

ENTRY /EVALUATION/ 
TERMINATION 

SERVICE 

PROCESS  CONSULTANT 
CHANGE  AGENT 

DIAGNOSIS  FACILITATION 
AND  TECHNIQUES 

DESCRIPTIVE 

"IT  ALL  DEPENDS ..." 


The  list  above  is  largely  self-explanatory.   The  technician's  role  is  seen 
as  one  of  isolation,  strongly  centered  around  expertise.   His  view  of  change  as 
being  a  process  of  'diffusion  of  innovation'  is  that  of  NASA;  potential  users 
are  kept  informed  of  new  developments  and  techniques  and  it  is  assumed  that 
they  will  recognize  their  value  and  adopt  them.   This  is  the  approach  that  led 
from  spaceship  nosecones  to  Teflon  frying  pans  but  it  does  not  get  refriger- 
ators into  the  hands  of  the  eskimos  who  need  them. 

Implementation  will  never  be  easy.   A  complex  model  or  system  is  an  in- 
vention.  It  has  never  existed  before  and  we  have  very  few  guidelines  for 
building  it.   Now  that  the  'easy'  triumphs  have  been  accomplished  -  the  auto- 
mation of  all  the  payrolls  and  accounts  receivable  in  the  world  -  future 
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innovations  will  almost  certainly  involve  qualitative  improvements  in 
decision-making  -  better  ways  of  doing  the  same  jobs,  and  new  jobs,  too.   In 
that  situation,  implementation  will  always  involve  a  range  of  users  over  a 
long  time-frame,  will  have  many  political  and  organizational  impacts  and  re- 
quire far  more  than  technical  skills  in  the  analyst.   This  paper  began  by 
quoting  pessimistic  figures  and  pessimistic  managers.   There  really  is  no  need 
for  pessimism.   We  have  substantial  insight  into  managing  change  in  organi- 
zations, the  technology  of  models  and  computer  systems  no  longer  seems  to  be 
the  critical  limiting  factor  and  we  have  a  new  generation  of  specialists  enter- 
ing the  Real  World  who  understand  the  technology  but  are  concerned  with  its 
wider  applications.   The  key  point  in  the  argument  here  is  to  suggest  that 
the  major  constraint  on  implementation  is  the  analyst's  view  of  his  role.   If 
he  can  recognize  that  implementation  is  not  the  same  as  design  and  that  he 
has  a  responsibility  to  create  the  climate  for  change  and  to  institutionalize 
the  change  he  introduces ,  then  he  can  be  immensely  effective  with  little  ad- 
justment  other  than  patience,  humility,  and  common  sense  (these  are  admittedly 
virtues  the  average  manager  does  not  associate  with  his  OR  whizkids).   The 
leverage  in  implementation  is  the  implementer  himself  and  his  control  and  in- 
fluence are  basically  determined  by  his  own  assessment  of  the  role  he  should 
play. 
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